home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 698 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. From: Mark.Baker@mettav.exnet.com (Mark Baker)
  2. Date: 06 Jul 94  13:27:52
  3. Message-Id: <UUCP.773547910@mettav>
  4. Subject: Re: available keys
  5. To: gem-list@world.std.com (gem-list@world.std.com)
  6. Precedence: bulk
  7.  
  8. Timothy:
  9.  >> I agree. I suggest that the difference between BKSP and shift BKSP would
  10.  >> be: BKSP can't delete CR while shift BKSP can (like in Edith).
  11.  >
  12.  > Shift-Backspace should do the same as Backspace, and CR is the same as
  13.  > any other character that can be deleted.  Are you putting physical
  14.  > returns at the ends of your lines within paragraphs?  Ick!
  15.  
  16. Definitely shift-BS and BS should be the same, as then you can use BS when
  17. still holding shift. I don't like Edith doing this but even worse Everest has
  18. this annoying way of deleting everything you've typed if you accidentally keep
  19. your finger on shift while deleting. Good thing the undo works :)
  20.  
  21.  > windows when they're clicked in not only confuse and frustrate people
  22.  > (myself included), but they often make simple things (like topping
  23.  > windows when you WANT to) difficult.
  24.  
  25. Especially on MultiTOS or with WinX - if none of the client area and none of
  26. the gadgets top the window it's a bit difficult :)
  27.  
  28.  > GEM is its own user interface, with its own peculiarities and traits and
  29.  > features that make it distinct from (and some times superior to) other
  30.  > GUI's.  Let's not go mucking that up in ways that we don't need to.
  31.  
  32. I agree. The standard should basically be writing down what is already good
  33. practice in GEM applications, not completely changing how GEM works. People
  34. might prefer the Mac, Xwindows, OS/2 or even possibly mswindows, but this isn't
  35. any of those, it's an Atari with it's own conventions.
  36.  
  37.  > I want my apps to work on people's computers without a lot of crap.  I
  38.  > don't want to have to confuse the user by having them install a new
  39.  > program in the AUTO folder to take up more memory just to add a few
  40.  > features to the OS, especially if they have to pay extra for this
  41.  > utility.
  42.  
  43. Obviously you can have your app enhanced by it, such as select multiple files
  44. with Selectric, or use skewed or rotated fonts with speedo, or help from
  45. ST-guide. What you shouldn't do is rely on it to work at all.
  46.  
  47. Mark-Oliver:
  48.  >> * Selectric      - German
  49.  > yep - the best fileselector around :)
  50.  
  51. Yes, although I've started using BoxKite now which is nearly as good and
  52. supports long filenames with minixfs.
  53.  
  54. Warwick:
  55.  >> Atari have done more damage with their guide lines.
  56.  >> They came too late when the standards de-facto have long been
  57.  >> established.
  58.  >
  59.  > What are we doing?
  60.  
  61. :) Anyway, I don't think standards had long been established. A lot of German
  62. programs used the Profibuch's standard but this was not used universally by a
  63. long way. What the standard should mostly be is a compilation of what is
  64. already good practice anyway.
  65.  
  66.  > Note that it's still non-modal in GEMforms and GEMhotforms.  Only for
  67.  > windows does it become modal.
  68.  
  69. So it's inconsistent. Oh dear... ;)
  70.  
  71. Michael:
  72.  > If there's no majority against APP_DEFS.SYS, then we must make sure that
  73.  > programmers have to support APP_DEFS.SYS.
  74.  
  75. Yes it must be supported universally or not at all. Otherwise the user will
  76. have some apps doing what is set by them in the app_sefs.sys file, and some
  77. using the normal shortcuts - and both supposedly conforming.
  78.  
  79.  
  80.  
  81.